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ABSTRACT 



Information in a database is accessed with a computer 
system by transforming a file system request from an 
application into a database query and retrieving information 
corresponding to the database query from the database. The 
retrieved information is made available to the application as 
a file system object, for example, as a directory, a file, a link 
or a collection thereof. 
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FILE SYSTEM INTERFACE TO A DATABASE programs that are written to accomplish a specific function. 

For example, a user may write a SQL program that retrieves 

REFERENCE TO MICROFICHE APPENDIX a list of customer names from a database which stores 

. . customer information. Alternatively, many different appli- 

Tnis apphcation includes a microfiche appendix having a 5 cation programs arc ava ii ab l e that support database queries 

total of 138 frames in 2 microfiche sheets. and which aUow a usef tQ interactively formulate a database 

BACKGROUND qUCry by s P ccif y in S an arbitrar y of criteria (e.g., the 

names of all out-of-state customers with overdue accounts). 
This invention relates to accessing information in a data- This type of application program presents the user's data- 
base. 10 base query to the database engine which retrieves the 
A database is a body of information that is Logically requested information from the database. Such application 
organized so that it can be retrieved, stored and searched in P^ams are referred to as database aware because they 
a coherent manner by a "database engine"— a collection of are have thc ablllt y to mtcract Wlth and manipulate data- 
software methods for retrieving or manipulating data in the bases. 

database. Databases generally fall into three categories: 15 Most application programs, in contrast, are "database- 
relational databases, object-oriented databases and object- unaware" meaning that they cannot access information 
relational databases. stored in a database. Rather, database-unaware applications 
A relational database (RDB) is a collection of fixed-field 00 file s y stems > such as the Network File System (NFS) 
two-dimensional tables that can be related (or "joined") to „ n developed by Sun Microsystems Inc for storing and 
each other in virtually any manner a database developer 20 retrieving information in discrete files. A database-unaware 
chooses. The structure of a relational database can be program stores each separate document m a separate d^k 
modified by selectively redefining the relationships between file identified by the user of the application. In FIG. 2, for 
thetables-Adatabaseenginemayperformcomplexsearches exam Pjf> a ^system 200 has two disk drives mounted: 
on a relational database quickly and easily by using any of ^ drive ^202 which is mapped to the label a: and drive 204 
various database query protocols such as the method 25 which is mapped to the label b:. Each of me a: and b: drives 
expressed by the Structured Query Language (SQL) or by j?dudes °^ or more dir^ectories (docs on the a: drive 202; 
other mechanisms. The relationships between the tables dirl and dir2 on the b: drive 204 ( which in turn may have 
enable results of a search to be automatically cross- subdirectories (subdirl in dirl; subdir2 and subdir3 in dir2) 
referenced to corresponding information in other tables in an and so on with virtu ^ level of hierarch f al nesUn g 
the database. As shown in FIG. 1, for example, a relational 30 bein S P 0SSlble - Flles 206 " 212 ma y at an / of the var ^ s 
database 100 includes a customer table 102 which is joined director y or subdirectory levels within the file system. The 
by a logical link 103 to an order table 104 which in turn is labels a - and b: ^present the "namespace of the file system, 
joined by a logical link 105 to an inventory table 106, A user ™at is > ^ filename P aths that be g m ™ th a: or *™ ™ tbin 
may query the database 100, for example, for all order ^ the file s y stem ' s namespace. As shown in FIG. 2, for 
numbers higher than a threshold value. Because the order 35 example, a document that lists names of out-of-state cus- 
table 104 is joined with the customer table 102 and the tomeis 15 storcd in ^ file s y stem s namespace at a location 
inventory table 106, the list of order numbers resulting from defined b y the filename path 
the query can be retrieved and displayed along with the a:\docs\cust_outstate.txt 

respective customer names and inventory items that corre- which means that a file 211 named "cusL_outstate" of the 

spond to the identified order numbers. 40 type "txt" is stored in a directory named docs on a disk drive 

An object-oriented database (OODB) is a collection of 202 ma P/ ed to the labe l a: " ^ oih&v d °cument that lists 

«objects"-software elements that contain both data and Dames of customers with overdue accounts is stored m a 

rules for manipulating that data. In contrast to a relational se P arate disk file located at * e filename P ath 

database which can store only character-type data, an OODB 45 a:\docs\cust_overdue.txt. 

can store data of virtually any type (text, 3D graphic images, These two files are separate and distinct entities that are not 

video clips, etc.). An OODB stores its constituent objects in related or joined in the sense that tables in a database are 

a hierarchy of classes with associated rules so that the related. 
OODB contains much of the logic it needs to do useful work. 

Arelational database in contrast contains only data and must 50 

rely on external application software to perform useful ] n one aspect of the invention, information in a database 

functions with the data. is accessed with a computer system by making one or more 

A object-relational database (ORDB) is a hybrid of the database objects (e.g., a table or a row) available as one or 

other two types. Non-character data (e.g., an image file) may more file system objects (e.g., directories, files or links) to an 

be stored and retrieved in an ORDB as a binary large object 55 application, for example, a database -unaware application, 

(BLOB) — an undifferentiated mass of data. Rules for The database may be relational, object-relation al or obj ect - 



manipulating the data contained within a BLOB (e.g., a oriented. If multiple me system objects are macie availab le, 
utility for viewing image files) may be stored either within collectively thev mav r epresent a hierarchical file system. A 
the database or external to it depending on the particular file system request issued by the application that co rre - 
ORDB implementation. The Informix® Universal Server 60 sfjonds to the file system object is transformed into a 
(IUS®) is an example of an object-relational database man- database operation, for example, an SQL query, which is 
agement system (ORDBMS) that internally stores the rules perform ed on the database with a database engine. 
for manipulating BLOBs so that they may be treated as Information associated with the database object which is 

"native" data types — that is, data types that the ORDBMS retrieved as a result of the database operation may be 
itself has the capability to manipulate. 65 formatted into one or more file system objects and returned 

Information within a relational or an object-relational to the application. The particular formatting of the retrieved 
database typically is accessed by SQL-compliant computer information may be defined in an extension module, which 
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also may include information that defines the specific man- prise's investment in database-unaware applications is 

ner in which the file system request should be transformed enhanced because IXFS enables them to be used to manage 

into a database query. The database operations, including data stored in a database. 

formatting of a database query, retrieving information and The ability for a database-unaware application to access 

formatting it into file system objects, are performed trans- 5 information in a database combines the simplicity of the file 

parently to the application. system paradigm with the sophistication and effectiveness of 

Upon receiving the file system objects, the application database manipulation techniques. This capability is particu- 

may display them on a display screen of a computer, for larly useful for Internet World Wide Web applications in 

example, as graphical representations of file system objects. which a user seeks to access a large store of data using, for 

The database object that is made available may be presented 10 example, the hypertext transfer protocol (HTTP). In contrast 

as multiple file system objects in formats understandable by to a common gateway interface (CGI) script, which spawns 

different applications. Conversely, a single file system object an external application to retrieve data from a database in 

may correspond to multiple database objects. response to a URL (Uniform Resource Locator) encoded 

In another aspect, a computer-based data repository man- request, the IXFS system converts such a request into a form 

agement system includes a database of information, a file 15 that may be executed by a database engine directly, quickly 

system-based application program for manipulating data, anc * transparently. 

and a file system interface to the database which provides the The ability to represent an arbitrary collection of tables in 

file system -based application, which otherwise may be a database as various file system objects provides a software 

database-unaware, with access to information in the data- developer with a rich and flexible set of tools. The extensible 

base. The data repository management system may further 20 nature of IXFS allows it to be tailored to virtually any type 

include a database management system which manages of application so that the database will appear as a collection 

information in the database either in addition to, or instead of file system objects that are consistent with the applica- 

of, the file system-based application. tion's other file system objects. 

The data repository management system may include a ^ Other advantages and features will become apparent from 

module for differentiating file system requests directed to the the following description, including the drawings and 

file system from file system requests directed to the file claims, 
system interface. The file system interface may include one 

or more extension modules containing one or more file BRIEF DESCRIPTION OF THE DRAWINGS 

objects, each file object including information for converting 3Q nQ x ^ a di ram of a relat ional database. 

database objects into file system objects. _ r , 

J i FIG. 2 is a diagram of a file system. 

In another aspect, information m a database is accessed „ . ,. T r , , , ■ C1 

with a computer system by encoding a file handle with FIG * 3 * a dia f a ™ of a s y stem for accessm S data m file 

information that specifies a database object in a database. In s y stem and m a d atabase - 

response to a file system request issued by an application, 35 FIG. 4 is a flowchart of accessing data in a database using 

the encoded file handle is transmitted and then decoded to the system of FIG. 3. 

identify the database object associated with the file system FIGS. 5A, 5B and 5C are example screen displays from 

request. The encoding may. be based on the NFS protocol. an application accessing information in a file system and in 

The encoded information may include information that a database. 

corresponds to the issued file system request and which ^ FI q 6 \s & data structure diagram for a file object, 

identifies an extension module, a database table and row, piG ? ^ a ^ of a kemd ]&ve] file system archi . 
metadata, a pointer to a database object, or a combination 
thereof. 

Advantages of the, file system interface described here . 

m ~^^^ Auctions that 45 FIG. 9 is a data diagram of a NFS file handle as used in 

] gf6n a file system as a data repository, or which I re the network file svstem architecture of FIG. 8. 

othe rwise database -unaware (i.e., unable to access data i n a DETAILED DESCRIPTION 
dataDase), are enabled to acces s information in a database in 

' ^transparent manner. ^T hese database -unaware applications The use of a database to store persistent data provides 

can share data seamlessly both with database- aware appli- 50 several advantages that are not available when a file system 

cations and with other database -unaware applications. is used as a data repository. The structure of a database, and 

Under IXFS, a database may appear to an application as just the internal relationships between tables within the database, 

another local or remote file system that is no different in enable fast and arbitrarily complex queries for information 

form or character from the other file systems available to the to be performed on the database. A file system in contrast has 

application. No change to the application's program code, 55 no standard data query mechanism for searching for specific 

the database or the database engine is required. As a result, data items within the files managed by the file system. Other 

users of database-unaware applications are provided with features provided by database systems for which conven- 

database functionality without having to invest the time and tional file systems have no analog include well-defined 

cost typically associated with database-aware tools. management policies, auditing capabilities, transparent data 

A system administrator may use the IXFS system to 60 replication, logging facilities, and consistent backup and 

combine disparate data storage technologies (e.g., file-based restore procedures. 

systems with database systems) in creating a unified data Using a database system as a data repository requires 

repository strategy that spans an enterprise. The enterprise's relatively complex and expensive tools, such as special 

investment in legacy data repositories is maintained because purpose database-aware applications, and often an increased 

data present in the repositories may easily be transferred to 65 level of sophistication and training by the end-user. File 

a database as the enterprise moves to the relational or systems in contrast generally are simple to use, cheap and 

object-relational model of data storage. Moreover, the enter- pervasive. Virtually every computer operating system pro- 



tecture. 

FIG. 8 is a diagram of a network file system architecture. 
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vides a native file system that may be used by applications a source other than a file system. In this manner, all requests 

for storing persistent data. This among other reasons is why for data in the file system's namespace are handled by the 

approximately 85-90% of all persistent data is stored in file file system while all requests for data in the file namespace 

systems by database-unaware applications. assigned to the database are handled by IXFS. 

The file system interface described here, dubbed the 5 An example of how IXFS may be used to represent a 
Informix® File System (IXFS) interface, provides computer datab ase as a file system to an application is provided with 
system users with the best of both worlds by enabling reference to FIGS 5A _ 5C . that a ^ of a window- 
database-unaware applications to access (i.e., read and based ut6r tem ^ a file s (em navigatioil tool to 
write) information in a database in a manner that is entirely ^ information (hat ^ stored ^ m me fifc system 
transparent to the application. No changes need to be made 10 n ^ b pjQ 2 and in the database represented by 
to the application or to the database. IXFS presents the pjQ L ^ mrther that the file system's namespace is 
contents of a database to the application as file system ented b me labels and b: ffld that IXFS is mapped 
objects such as dnectones, sub-directones, files or links. tQ ^ x; Qn ^ ^ ^ shown fa K ^ 
These file system objects appear to the application to be no ^ ^ window ^ , ^ fi , e 
different .n form or character from the file system objects „ tem . g ^ a; ^ aQd ^ dfive x . ^ di 
that the application handles in the ordinary course of storing (q ^ da fa a cq1 , d ^ A , ^ mt ^ user 
and retrieving data. IXFS enables a user of a database- ^ navi tion ^ tQ d drive b:> 
unaware application to access the contents of a database by m hie Qf direclories and subdirectories visible 
performing the desired operations on the file system objects (o ^ ^ subdirl wmch tWQ fil 
that represent the database s contents. A funcUonal specifi- M doc206 ut aad doc2 07.txt, as showrj ia FIG. 5B. The file 
cation for IXFS is reproduced as Appendix A, winch is infonnation displayed in mG . 5B is retrieved from the a: and 
incorporated by reference. b . ^ fik ffl ations _ 

As shown in FIG. 3, IXFS 300 sits between a database- vT . . . • 

i- .• in-i j j.u w j Next, the user instructs the navigation tool to expand drive 

unaware application 302 and a database 304 and monitors all , .', . , ^ . . . . & . ™.™ r ..... 

. - j. .u ci , „mici. .i. „ «„.ri im x:, which is mapped to the database via lXrS, so that the 

requests issued to the file system 306 by the application 302. 25 , r . • . • j ™ .■_ 

,. .... , , • c „ • tu contents of dnve x: may be examined. Because the corre- 

When the application seeks to access information in the ' .... • .• . , 

c ^tab^c^po- nent of the IXFS sys tem taS lagTEc file s P ondln 8 s y stem « ued b y thc navigation tool 

— - z v . . J —c — "1 . ■ j points to drive x: — the file namespace assigned to the 

system request into a database query format that is under- ^ TV ™ . ., .. n , . . . 

£sxv, > ■ .T— . . >, iii . — ■ . - , database — IXFS handles the file system request by passing 

sTanda ble b v thtHJajahase. Similarly, information received . 

<• ".t j . t. . i-1 < _ j . . it to an extension module which formulates a database query 

from the database (in response to a file system read request 30 . .1 

... .... v . x • , , . ,, .• to retrieve the requested information from the database. 

by the application, for example) is represented to the appli- . . , , , . . -. ■ r .. , • . 

\. rr ci . u- . After the information has been retrieved, it is formatted into 

cation as one or more rile sys tem obiec ts. . . . _. . ' , , lvrx , , 

. , . _, -. — s — ^ . c a ■. file system objects with a method invoked by IXFS and 

-^irpeveraescription of the operation of IXFS and its tQ ^ navi ^ ation tool ^ infonnation retlieved 

interaction with the computer s operating system is provided from the , o ^ Mvi ation tool and to the 

with reference to the flowchart of FIG. 4. When a file system 35 user of (he navi ati ^ n tool> to be no different m cnaracter 

request (e.g. a data read or write) is issued by an application from othef ^ em g ^ wefe retrieved ^ me 

program, the operating system determines whether it corre- fi]e ^ ^ shown jn pjQ 5C tabks W2 W4 Md 106 

sponck tc '^formation contained in a file namespace man- me database lw Qf nG j ^ „ ^ „ three 

aged by IXFS (step 400). The operating system is able to ^ ndi directories-customer, order and inventory, 

differentiate requests for data stored in other file systems 40 similarl three rows ^in the customer table 102- 

from requests for data in IXFS s file namespace because the customer nam customer _ addr md _i d _ are 

database has been mapped to a namespace (e.g., x:) that is w ^ as mree comspoalliBg subdirectories within the 

mutual y exclusive with the file system s namespace (e.g., a: customer directo _ nam address and id . Entries in the 

and b:). In effect, the database appears to the operatmg name subdirect m r resented as text ^ es tnat are 

system and to the application as a disk drive mapped to the 45 Qamed for ^ respective contenb-Adams, Andrews, 

label x:. Brewster etc. 

If the file system request is not directed towards infor- . ' ' ^ . . c , • 

j 1 T ™ 0 t . . . i Ji j t« it, A user may open any of the text files in the 

mation managed by IXFS, the request is handled by other x I- > ,c 1 ,u * a a 

a , t .ft-v lf , u . , t . ci„ „„.#^ x:\customer\name directory (for example, with a standard 

file systems (step 401). If, on the other hand, the nle system \ ,. v . V : . _r 

, j / • • tvoc/ ^ text editor application) modify its contents, and perform a 

request corresponds to information in IXFS s nle 50 ■ ,„„, rr ' . t , r „ iU 

n iL r t . . t standard file save operation. In response, IXFS handles the 

namespace, the operating system passes the request onto . r . . 4 r , 4 . ' £1 

rvr^o u* u • . t • i. *t. *» * ui^ file save request because it is directed to the file namespace 

IXFS which in turn furnishes the request to an extensible ,r i* j- 

. £ tvi-o • u * • j i f * assmned to the database and formulates a corresponding 

component or IXFS, i.e., an extension module, for trans- t ° . A . , 4 r . , /, e 

, t . r . „ - j ' . U1 . . . . ' cr^r database operation to modify the contents 01 the database as 

lation into a form understandable by the database — an SQL F ' 

query, for example— (step 402). After the request has trans- 55 a PP ro P nate - 

lated into a database query, the IXFS extension module 1XF S allows a11 file system operations to be performed on 

presents the query to the database engine which uses it to l h e database. For example, a user could employ appropriate 

access the database either by modifying the desired infor- features of the navigation tool to change the name of the 

mation (for a write request) or by retrieving the desired x:\customer directory to something else such as x:\cust. 

information (for a read request) and returning it to IXFS 60 Similarly, a user could create a new file system object such 

(step 404). If information has been retrieved from the as a subdirectory or a new file underneath the x:\customer 

database (step 406), the IXFS extension module formats it directory. Moreover, access to specified portions of the 

according to predefined criteria into file system objects (step database could be limited for certain users in the same 

408) which are presented to the application (step 410). Upon manner that file system objects in a file system may be 

receiving the file system objects from IXFS, the application 65 limited (read only, hidden, etc.). 

treats them as if they came from a file system. In fact, the The specific types, formats and arrangement of file system 

application is unaware that the file system objects came from objects that IXFS will return in response to a file system 
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request are defined in a corresponding extension module — a 
software component of IXFS that may be tailored as desired 
to encapsulate an arbitrary collection of database objects 
(e.g., tables) and represent them as a collection of file system 
objects. In one implementation, IXFS includes a Basic 5 
Extension Module (BEM) that provides a one-to-one map- 
ping of a file in a file system into a collection of database 
objects. Among other uses, the BEM allows users to quickly 
and transparently move their data from a file system into the 
IUS™ database management system and run database que- 
ries against it. The source code for the IXFS BEM is 
reproduced in the microfiche appendix. 

The BEM emulates a file system by encapsulating a 
collection of database tables as specified by a software 
developer implementing the IXFS system, and presenting 15 
them to an application as file system objects. Each table 
specified by the BEM corresponds to a directory and each 
row in the table corresponds to a file system object (e.g., 
subdirectory, file or link) present within the directory. 

For each database table that it encapsulates, the BEM 2 o 
includes a corresponding "file object" 600 having a data 
structure as shown in FIG. 6. The file system object 600 
corresponds to, and provides an intuitive representation of, 
a directory, a file or a link in a file system. Each file object 
600 includes the file object's name 601 (an identifier of a file 25 
system entity that is unique within a given directory), type 
602 (directory, file or link), ownership 603 (an identifier of 
the file object's owner), access rights 604 (access rights to 
the object for its owner, community and others), temporal 
characteristics 605 (timestamp of last read, write and look- 30 
up operations), popularity 606 (number of links pointing to 
the object) and size 607 (object's size in bytes). The file 
object 600 also contains its corresponding data object 608 or 
a pointer to the data object. 

Portions of a database are mapped to a file system 35 
representation by selecting database tables and rows as 
desired, and by designating the type of file system object to 
which each selected table and row corresponds. For 
example, the database of FIG. 1 was mapped into the file 
system hierarchy shown in FIG. 5C by specifying that each 40 
of the customer, order and inventory tables occupy a sepa- 
rate file object in the BEM of the type "directory." Within the 
file object for the customer table, each of the name, address 
and id rows have been designated as the type "directory/' 
thereby making them appear as subdirectories to the hier- 45 
archically dominant customer directory. Within the "name" 
row in the "customer" table, the individual customer name 
entries have been designated in the file object as the type 
"file" making them appear as individual text files as shown 
in FIG. SC. 50 

Several different IXFS extension modules may be resident 
and operative at the same time to provide access to two or 
more different databases simultaneously or to access differ- 
ent information within the same database or to provide a 
different interpretation of the same database object. A single 55 
extension module is capable of presenting the same infor- 
mation in multiple different formats, for example, as differ- 
ent types of file system objects. In Fig. 5C, for example, the 
table of customers, including their names, addresses and 
IDs, could be presented as a single file system object — e.g., 60 
a Microsoft Excel file named "customer.xls" containing all 
of the customers' identifying information — which could be 
opened by an appropriate spreadsheet program that under- 
stands the "xls" format. The extension module could be 
configured so that the customer.xls file object is presented to 65 
the application either instead of, or in addition to, the 
x:\customer directory, its component subdirectories (name, 
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address, id) and the files contained therein (Adams.txt, 
Andrews.txt, Brewster.txt, etc.). 

As anoth er example, an extension module could be con- 
fi gured to present the text~ni es m x:\customer\name in 
several different formats tor use oy alternative appitcati on 
programs. In the database of FIG. 1, tor example, mu ltiple 
d iffere nt fi le fo^rriats c ould be provi ded foreach c ustome r 
namely presenting multiple file system objects fo r _a single 
databa se obj ect. The database table entry foTtfae customer 
Aaams, IcbuJa oe mapped, for example, to three separate file 
system objects having different formats: "Adams.doc" for 
use with Microsoft Word, " Adams. wpd" for use with Corel 
Wordperfect, and "Adams.fm" for use with Adobe Frame- 
maker. A user who edited the information in the "Adams, 
doc" object would observe that the changes automatically 
were reflected in the "Adams.wpd" and "Adams.fm" 
objects. Because all three of the file system objects are 
mapped to the same database object (namely, the database 
entry for customer Adams), the three alternative file system 
objects may be used interchangeably to view or edit the 
information for customer Adams without concern that diver- 
gent versions of Adams), information will result. 

By employing the appropriate extension modules, 
whether obtained from a software library or generated 
according to custom specifications, software developers may 
enable database -unaware applications (e.g., Microsoft Word, 
Microsoft Excel, Lotus 1-2-3) to retrieve information stored 
in a database or to store new or modified information into the 
database. At the same time, database-aware applications 
may continue to access all of the information stored within 
the database, including information that was stored by 
database-unaware applications in the first instance. Together 
these capabilities enable a single enterprise- wide data 
repository to be maintained with various different 
applications, both database-aware and database -unaware, 
being able to access the information in the data repository. 
Moreover, IXFS facilitates the migration of data between 
different applications — for example, between a database- 
aware application and a database -unaware application or 
between two disparate database-unaware applications. 

The IXFS system may be implemented by three different 
architectures: an object library architecture; a kernel level 
mountable file system architecture; or a network file system 
architecture. Details for implementing these three architec- 
tures are set forth ,in the IXFS Functional Specification, 
Appendix A. ^ 

In the first approach, the object library architecture, the 
ability to access information in a database is achieved 
through a set of software objects made available to database- 
unaware applications through a library — for example, a 
dynamic linked library (DLL) on a Microsoft Windows®- 
based platform. Using a consistent set of file system access 
methods that operate on the database, these software objects 
provide a functionality analogous to that provided by the 
common file access Application Program Interfaces (APIs) 
defined by the ANSI C or POSIX standards. Use of the 
object library architecture would require, however, any 
application to be used with the IXFS system first to be 
relinked with a new library of IXFS -related objects. The 
other two architectures, in contrast, allow existing applica- 
tions to access database information without any changes to 
or relinking of the applications. 

The kernel level mountable file system architecture, illus- 
trated in FIG. 7, intercepts file system requests at the 
operating system level and passes them on to the IXFS 
system for processing. In the kernel architecture, the kernel 
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address space 700 is modified to include an IXFS kernel 32-byte value — to identify a desired file. When NFS is used 

module 701 which is specific to the operating system being as the network file system protocol in the network 

used (e.g., UNIX, Windows® NT). File system requests architecture, IXFS can make additional use of the NFS file 

from application programs are received by the OS kernel handle to achieve greater speed and efficiency in performing 

702 either from a local client 705 (an application residing in 5 file system requests on the database. To do so, IXFS encodes 

the address space of the local host 704) or from a remote the NFS file handle with information that is specific to its 

client 706 (an application residing in the address space of a operations as shown in FIG. 9. 

remote system) via NFS 703. Bytes 1-8 of the file handle hold the IXFS "magic 
File system requests directed towards the namespace of string" — an entity that allows IXFS to distinguish IXFS file 
the mounted file system devices (e.g., disk drives) are 10 handles (i.e., file system requests directed to the file 
handled by NFS 703 in the conventional manner. File system namespace assigned to the database) from NFS file handles 
requests that are directed to the namespace occupied by the (i.e., file system requests directed to the file namespace 
database (as determined by the IXFS kernel module 701) are assigned to the file system). The magic string is an eight byte 
passed onto the IXFS daemon 708 (or the IXFS "service" in string in which each byte is assigned the value FF hexa- 
the case of Windows NT) for processing. The IXFS daemon 15 decimal to identify a file handle as an IXFS file handle, 
708 performs several functions including managing connec- Bytes 9 and 10 identify the particular IXFS extension 
tions to the database 709 (or databases) to be accessed and module whose job it is to manage the file handle under 
maintaining a list of the filenames being used to access consideration. Encoding an IXFS file handle in this manner 
database objects. Upon receiving a request from the IXFS obviates the need to maintain an empty ("shadow**) directory 
kernel module 701 to access the database 709, the IXFS 20 tree in the file system, which otherwise would be needed to 
daemon initializes a filename look-up procedure to identify generate standard NFS file handles that correspond to infer- 
tile appropriate IXFS extension module 707 to handle the mation managed by the IXFS system. Similarly, this encod- 
request. The filename specified by the request is used as an ing scheme makes it unnecessary to maintain a distinct 
index into a look-up table of corresponding IXFS extension mapping entity (e.g., look-up table) between NFS file 
modules by comparing the specified filename to a list of 25 handles and IXFS file handles. 

names of file objects contained in each extension module. The remaining bytes of the NFS file handle in FIG. 9 
After determining which IXFS extension module includes a include information that is specific to the extension module 
file object whose name matches the specified filename, the identified by the extension module identified by bytes 9 and 
IXFS daemon 708 transfers the request to that extension io 0 f the file handle. Bytes 11-14 and 15-18 respectively 
module 707. The extension module translates the request 30 identify the database table and row that correspond to the file 
into a database operation which is performed on the database handle. Bytes 19-22 identify the i-node (information node) 
709. Any information generated in response to the database table and row which correspond to metadata descriptive of 
query operation is formatted by a method invoked by the fife attributes, and a pointer to the data in the database, for 
IXFS extension module 707 into file system objects accord- t he file handle under consideration. Bytes 19-32 presently 
ing to the file object types defined in the extension module. 35 are unuS ed but they are available for use by any newly 
The formatted file system objects are then presented to the developed extension modules. As a result of the encoding 
requesting application. represented in FIG. 9, the efficiency with which elements 
The network architecture, illustrated in FIG. 8, intercepts may be located in the database is enhanced and the corn- 
file system requests at the network level and passes them on plexity of designing new IXFS extension modules is 
to the IXFS system for processing. In the network 40 reduced. 

architecture, the OS kernel address space need not be The kernel level and network architectures provide dif- 

modified. Rather, all file system commands generated by a ferent advantages relative to one another. The kernel level 

local client 805 or a remote client 806 are passed, via a loop approach is the more efficient of the two in that it provides 

NFS connection 810 or a network NFS connection 803, to ^ a shorter data path between the issuance of the file system 

a NFS front-end daemon (or service) 804, which resides request to the return of file system objects from IXFS. On the 

outside of the OS kernel. The NFS front-end daemon 804 is ome r hand, the network-based architecture significantly 

implemented as a component of the IXFS daemon. minimizes the effort required to port the IXFS between 

Upon receiving a file system request, the NFS front-end different platforms because implementing the network archi- 

daemon 804 passes it on to the IXFS daemon 806 and 5Q tecture does not require a modification to the operating 

subsequently to the appropriate IXFS extension module 807, system kernel. In both cases, however, the IXFS system 

which provide the same functionality as the IXFS daemon provides a database -unaware application with transparent 

and IXFS extension modules in the kernel level architecture access to data in a database, while maintaining the inherent 

described above. advantages of using a database for persistent data storage. 

The IXFS system can be adapted to provide an interface ss The methods and mechanisms described here are not 

to any type of database, including relational, object- limited to any particular hardware or software configuration, 

relational and object-oriented databases, and to understand but rather they may find applicability in any computing or 

any other type of database query protocol in addition to processing environment in which database manipulation 

SQL. NFS was chosen as the network protocol to be used in may be performed. 

the IXFS implementation of FIG. 8 because NFS is a widely 60 The techniques described here may be implemented in 

used standard for sharing files across different platforms. hardware or software, or a combination of the two. 

However, any other network protocol that provides access to Preferably, the techniques are implemented in computer 

file systems over a network — for example, Microsoft's programs executing on programmable computers that each 

Common Internet File System (CIFS) — couldbe used in include a processor, a storage medium readable by the 

implementing the IXFS network architecture. 65 processor (including volatile and non-volatile memory and/ 

The NFS protocol (version 2) allows clients and servers to or storage elements), and suitable input and output devices, 

exchange file information by using a "file handle" — a Program code is applied to data entered using the input 
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device to perform the functions described and to generate 14. The method of claim 13 in which the database query 

output information. The output information is applied to one comprises an SQL-compliant query, 

or more output devices. 15, The method of claim 1 in which the transforming 

Each program is preferably implemented in a high level comprises converting the file system request into a database 

procedural or object oriented programming language to 5 q ue ry based on information contained within an extension 

communicate with a computer system. However, the pro- module. 

grams can be implemented in assembly or machine 16. The method of claim 1 further comprising determining 

language, if desired. In any case, the language may be a whether the received file system request corresponds to 

compiled or interpreted language. information managed by a file system. 

Each such computer program is preferably stored on a 10 17. The method of claim 16 further comprising conveying 

storage medium or device (e.g., CD-ROM, hard disk or the file system request to the file system if the file system 

magnetic diskette) that is readable by a general or special request & determined to correspond to information managed 

purpose programmable computer for configuring and oper- by the file system 

ating the computer when the storage medium or device is 18. The method of claim 16 in which the determining 

read by the computer to perform the procedures described in comprises identifying a namespace to which the file system 

this document. The system may also be considered to be 1 request is directed. 

implemented as a computer- re ad able storage medium, con- 1». The method of claim 16 in which the determining is 

figured with a computer program, where the storage medium performed by a method executing in a kernel address space 

so configured causes a computer to operate in a specific and of an operating system associated with the computer system, 

predefined manner 20. The method of claim 16 in which the determining is 

Other embodiments are within the scope of the following 20 performed by a method executing external to an operating 

claims system associated with the computer system. 

What is claimed is* 21. ^ e melnod of clami 1 m wmcD the database object 

1. A method, performed on a computer system, of access- co !^ r * es a , • u-u*u*i * u- * 
ing information in a database, the method comprising: 22/ Themethodof d^l in «^ the file system object 

making information corresponding to a set of database 25 com P r ^ s ^^"1 ^ Tm which making the infor- 

objects available as a file system structure having one ^ as & me gystem pre . 

or more nic system oojects, ^ ^ information as lural file system by ob j ects in 

receiving from an application a file system request cor- fonna * understandable b different applicalions . 

responding to the available one or more file system ^ comprising, prior to 

obiects; and 30 , . , . - ., . , • * • 

i . . „, 4 . , ,. making the information available, accessing an extension 

transforming toe file system request from the application * » or 

into a database operation; wherein making the mfor- y J 

mation available as a file system structure having one system structure or Dotb. 

, . , . / , . t . . t . 25. A computer-based method of accessing information in 

or more file objects is performed transparently to the *; . . & 

r J r „ a database, the method comprising: 

application. 35 . .^,. L 

2. Hie method of claim 1 further comprising performing retrieving information corresponding to a set of database 
the database operation on the database using a database ob J ects from the database; and 

engine. presenting the retrieved information to an application as a 

3. The method of claim 1 further comprising retrieving file structure having one or more file system 
information from the database in response to the database 40 objects; accessing, prior to retrieving information, an 
operation extension module that specifies the sets of database 

4. The method of claim 1 further comprising returning the objects or the file structure or both. 

information associated with the database object to the appli- 26. The method of claim 25 further comprising identify- 

cation as a file system object. im S the information to be retrieved from the database by 

5. The method of claim 4 in which the returning comprises 45 specifying a database object from among database objects in 
arranging the retrieved information in a format defined in an tne database. 

extension module. 27. The method of claim 26 in which the identifying 

6. The method of claim 5 further comprising displaying comprises recording in an extension module information 
the formatted information on a display screen of a computer. descriptive of a predetermined set of database objects. 

7. The method of claim 1 further comprising displaying 50 28. The method of claim 27 in which the retrieving 
information associated with the database object on a display comprises selectively extracting information from the data- 
screen of a computer. oase oase d on information contained in the extension mod- 

8. The method of claim 7 in which the information u ^ e - 

associated with the database object is displayed as a graphi- 29. The method of claim 27 in which the presenting 

cal representation of a file system object. 55 comprises formatting the selectively extracted information 

9. The method of claim 1 in which the application that into the file system structure having one or more file system 
issued the file system request comprises a database-unaware objects based on information contained in the extension 
application. module. 

10. The method of claim 1 in which the database com- 30. The method of claim 25 in which the file system 
prises a relational database. 60 structure represents a hierarchial file system having 

11. The method of claim 1 in which the database com- directories, files, links or a combination thereof. 

prises an object-relational database. 31- A computer-based data repository management sys- 

12. The method of claim 1 in which the database com- tem comprising; 

prises an object-oriented database. a database of information organized into database objects; 

13. The method of claim 1 in which the transforming 65 a file system-based, database -unaware application pro- 
comprises converting the file system request into a database gram for manipulating data in the form of file system 
query. objects; and 
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a file system interface to the database which makes 
information corresponding to a set of database objects 
available to the file system-based application as a file 
system structure having one or more file system 
objects. 5 

32. The system of claim 31 in which the file system-based 
application is database -unaware. 

33. The system of claim 32 in which the database com- 
prises an object-relational database. 

34. The system of claim 32 in which the database com- 10 
prises a relational database. 

35. The system of claim 32 in which the database com- 
prises an object-oriented database. 

36. The system of claim 33 further comprising a database 
management system for managing information in the data- 15 
base. 

37. The system of claim 31 further comprising a database 
engine for performing database operations on the database, 
the file system interface receiving file system requests and 
transforming the received requests into a form understand- 20 
able by the database engine. 

38. The system of claim 31 further comprising a module 
for differentiating file system requests directed to the file 
system from file system requests directed to the file system 
interface. 25 

39. The system of claim 31 in which the file system 
interface further comprises an extension module that 
includes a file object. 

40. The system of claim 39 in which the file object 
comprises information for converting database objects into 30 
file system objects. 

41. The system of claim 31 in which -the file system 
interface comprises a plurality of extension modules each of 
which includes information for converting a different set of 
database objects into file system objects. 35 

42. The system of claim 31 in which the file system 
interface comprises a plurality of extension modules each of 
which includes information for converting a single database 
object into multiple file system objects, 

43. The system of claim 31 further comprising an exten- 40 
sion module that specifics the set of database objects or the 
file system structure or both. 

44. A computer program, residing on a computer readable 
medium, for a data repository management system compris- 
ing a file system-based, database-unaware application and a 45 
database, the computer program comprising instructions to 
cause a computer system to perform the following opera- 
tions: 

receive a file system request issued by the file system- 
based application; 50 

convert the file system request into a database operation; 

retrieve information corresponding to a set of database 
objects from the database by performing the database 
operation on the database; 55 

transform the retrieved information into a file system 
structure having one or more file system objects 
according to predetermined criteria; and 

present the one or more file system objects to the file 
system-based application. 
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45. The software of claim 44 further comprising instruc- 
tions that access an extension module that specifies the set 
of database objects or the file system structure or both. 

46. A method, performed on a computer system, of 
accessing information in a database, the method comprising: 

making information corresponding to a set of database 
objects available to a database-unaware application as 
a file system structure having one or more file system 
objects; 

receiving from the database-unaware application a file 
system request corresponding to the available file sys- 
tem structure having one or more file system objects; 

transforming the file system request from the database - 
unaware application into a database operation; 

performing the database operation on the database using 
a database engine; 

retrieving information from the database in response to 
the database operation; and 

returning the information associated with the database 
object to the database-unaware application as one or 
more file system objects. 

47. The method of claim 46 further comprising, prior to 
making the information available, accessing an extension 
module that specifies the set of database objects or the file 
system structure or both. 

48. A computer-based method of accessing information in 
a database, the method comprising: 

encoding a file handle with information that specifies a set 
of database objects in a database; 

transmitting the encoded file handle in response to a file 
system request issued by a database -unaware applica- 
tion; and 

decoding the received file handle to identify the set of 
database objects associated with the file system request. 

49. The method of claim 48 in which the encoding is 
based on the NFS protocol. 

50. The method of claim 48 in which the encoding 
comprises including information in the file handle that 
identifies an extension module that corresponds to the issued 
file system request. 

51. The method of claim 48 in which the encoding 
comprises including information in the file handle that 
identifies a database table and row that correspond to the 
issued file system request. 

52. The method of claim 48 in which the encoding 
comprises including information in the file handle that 
identifies metadata that corresponds to the issued file system 
request. 

53. The method of claim 48 in which the encoding 
comprises including information in the file handle that 
points to the set of database objects that correspond to the 
issued file system request. 

54. The method of claim 48 further comprising, prior to 
encoding the file handle, accessing an extension module that 
specifies the set of database objects. 

***** 
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